home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930265.txt < prev    next >
Internet Message Format  |  1994-06-04  |  4KB
  1. Date: Tue, 12 Oct 93 04:30:01 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #265
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue, 12 Oct 93       Volume 93 : Issue  265
  11.  
  12. Today's Topics:
  13.                               BPQ 406 K
  14.                      lzw implementation problems.
  15.                               Subscribe
  16.  
  17. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  18. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  19. Problems you can't solve otherwise to brian@ucsd.edu.
  20.  
  21. Archives of past issues of the TCP-Group Digest are available
  22. (by FTP only) from UCSD.Edu in directory "mailarchives".
  23.  
  24. We trust that readers are intelligent enough to realize that all text
  25. herein consists of personal comments and does not represent the official
  26. policies or positions of any party.  Your mileage may vary.  So there.
  27. ----------------------------------------------------------------------
  28.  
  29. Date: Mon, 11 Oct 93 20:49:47 GMT
  30. From: nick@plains.demon.co.uk (nick button)
  31. Subject: BPQ 406 K
  32. To: tcp-group@ucsd.edu
  33.  
  34. Hi there,
  35. I've uploaded version 4.06K of G8BPQ node software for the PC and the kantronics
  36. Data-Engine to ucsd.edu:/hamradio/packet/tcpip/incoming .
  37. The files are BPQ406K.ZIP and KANT406K.ZIP respectively.
  38.  
  39. 73
  40. de Nick G4IRX
  41.  
  42.  
  43. .. ick..
  44. ==========================================
  45. | Nick Button,       Nottingham, England |
  46. | Internet:- nick@plains.demon.co.uk.    |
  47. ==========================================
  48.  
  49. ------------------------------
  50.  
  51. Date: 11 Oct 93 15:12:49 CDT
  52. From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
  53. Subject: lzw implementation problems.
  54. To: <TCP-Group@UCSD.Edu>
  55.  
  56.    I'm looking at adding lzw sockets to pop3 sessions and telnet
  57. sessions.  I'm a little confused on how the lzw stuff works.
  58.  
  59.    Using the smtp code as a base, it looks like the only thing you
  60. really need to do to add lzw compression to a socket is to issue the
  61. lzwinit() command for a socket.  The lzwinit command needs to know the
  62. number of lzwbits and lzw compression method.
  63.  
  64. Is there anything else that needs to be done?
  65. Is there a way to go from lzw type sockets to standard sockets?
  66.  
  67.    I have sort of successfully added lzw compression to the POP3 code,
  68. but there is a problem.  Instead of sending a few tcp window sized
  69. packets, the system sends dozens of 20 - 50 byte size packets.  The
  70. added overhead of the increased number of packets is greater than
  71. sending the uncompressed pop3 data packets.
  72.  
  73.    As for telnet sockets, I've added a TN_LZW option to the telnet
  74. initialization stuff.  When a client connects, the server sends a 'DO
  75. TN_LZW' similar to the DO TN_ECHO command and does a lzwinit() to start
  76. the compressed sockets.  ( I need to figure out how to read a 'WILL
  77. TN_LZW' from the client before I do the lzwinit(). ) The telnet client
  78. get's the 'DO TN_LZW', starts the lzwinit() and and returns the 'WILL
  79. TN_LZW' to the server.
  80.    I'm having all sorts of problems here. Seems like only one side is
  81. doing the lzwinit() correctly. I'm getting lots of lzw protocol errors.
  82. If I remove the lzwinit() call from both the client and server, my
  83. debug messages say that both the client and server agree to the lzw
  84. stuff and start the lzw stuff on the correct sockets. Can't figure out
  85. what's going on when they actually do do the lzwinit(). I think that
  86. one of them may being doing the lzwinit() call too early and getting
  87. hosed when more non-lzw data is sent.
  88.  
  89.    If anyone has any ideas on this please let me know. Also, am I going
  90. about this the wrong way? Is there a way to add lzw compression to all
  91. sockets ( related to a specified system )  instead of for each client/
  92. server pair. Seems like this would be a better way to go. Has this idea
  93. been looked at before and tossed? Thanks.
  94.  
  95. 73's  de  Jack  -  kf5mg
  96. Internet        -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
  97. Worknet         -  kf5mg@vnet.ibm.com         - work (817) 962-4409
  98. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
  99.  
  100. ------------------------------
  101.  
  102. Date: Mon, 11 Oct 93 10:02:10 CDT
  103. From: mfoster@amoco.com (Michael H. Foster)
  104. Subject: Subscribe
  105. To: tcp-group@ucsd.edu
  106.  
  107. Subscribe
  108.  
  109. ------------------------------
  110.  
  111. End of TCP-Group Digest V93 #265
  112. ******************************
  113. ******************************
  114.